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SPECIFICATION 
Attorney Docket No. 12870US03 
TO ALL TO WHOM IT MAY CONCERN: 

Be it known that we, F. Van Baltz, a resident of the city of Las Vegas, NV, 
Stephanie Maddocks, a resident of the city of Las Vegas, NV, Michael H. D'Amico, a 
resident of the city of Las Vegas, NV, Alan G. Sheldon, a resident of the city of North 
Las Vegas, NV, Lori J. McDermeit, a resident of the city of Las Vegas, NV, J. 
Christopher McNamee, a resident of the city of Las Vegas, NV, all of the United States 
have invented certain new and useful improvements in an 

APPARATUS AND METHOD FOR A CASHLESS 
ACTUATED GAMING SYSTEM 


of which the following is a specification. 


CROSS-REFERENCE TO RELATED APPLICATION 

This is a continuation of U.S. Application Serial No. 09/693,183 entitled 
APPARATUS AND METHOD FOR A SECURE TICKET ACTUATED GAMING 
SYSTEM filed October 19, 2000. 

STATEMENT REGARDING FEDERALLY 
SPONSORED RESEARCH OR DEVELOPMENT 


Not applicable. 


FIELD OF THE INVENTION 


The present invention relates generally to a ticketing gaming system and, more 
particularly, to a gaming system that encompasses printing and validation of tickets with 
ticket validation numbers pre-loaded by a central computer system to individual gaming 
machines. 


BACKGROUND OF THE INVENTION 


Gaming machines, particularly slot machines, have in recent years become one of 

5 the more popular, exciting, and sophisticated wagering activities available at casinos and 
other gambling locations. At the same time, slot machines have also become a source of 
greater revenue for gaming establishments. 

Typically, a player, when finished playing, "cashes out" at the slot machine by 
activating a cashout button. At that time, the slot machine converts the amount of credits 

10 pending in the slot machine to a currency payout that is dispensed (e.g., as coins) to the 
player. The player must then collect all of the coins, fill a cup or pockets, then move to 
the next slot machine and reenter all of the coins. Thus, the prior payout techniques 
tended to interrupt gameplay, thereby reducing profits and also reducing the excitement 
and entertainment experience that arise from uninterrupted game play. 

15 In the past, slot machines have attempted to address the interruption caused when 

a player collects coins and moves to another slot machine. In particular, some slot 
machines have issued paper tickets that encode the amount of credit pending in the slot 
machine when the player presses the cashout button. The player may then simply pick up 
the ticket dispensed by the slot machine and proceed to a new slot machine without 

20 incurring the time delay and distraction associated with collecting currency and 
reinserting it into the new slot machine, 

Successfiil ticketing, however, requires a comprehensive system level approach to 
ensure that the tickets are secure (e.g., they cannot be dupUcated and reused, they cannot 
be forged, and the like), that as many slot machines as possible can accept tickets, and 
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that ticketing does not cause as much interruption as the coin / currency payout that the 
tickets are designed to replace. However, in prior ticketing systems for example, the slot 
machines typically had to spend the time and processing resources to generate their own 
ticket validation numbers, or had to incur the delay of requesting a ticket validation 
number from a central authority each time the slot machine needed to print a ticket. As a 
result, prior slot machines exposed the player to unnecessary processing delay, thereby 
slowing play, and reducing the overall level of player enjoyment. 

A need has long existed in the industry for a secure ticket actuated gaming system 
that addresses the problems noted above and other previously experienced. 


SUMMARY OF THE INVENTION 


A preferred embodiment of the invention provides a method for issuing validated 
tickets to a gaming machine player. The method includes pre-loading a ticket validation 
5 number from a central authority to a network interface board connected to a gaming 
machine, tracking pending credit in the gaming machine, and monitoring at the gaming 
machine for a cashout signal. In response to the cashout signal, the method proceeds by 
printing a ticket including pending credit indicia and pre-loaded ticket validation indicia 
obtained from the interface board. In general, when a ticket vahdation number is pre- 
y 10 loaded onto the network interface board, the ticket validation number is also pre-stored in 
S a ticketing database (albeit without an associated pending credit amount). Thus, should 

m the gaming network fail, validation may still occur through human intervention. 

m After the pre-loaded validation number is used, the method pre-loads a subsequent 

0 ticket validation number from the central authority into the network interface board in the 

gaming machine in preparation for printing a subsequent ticket. Thus, the gaming 
H machine does not wait for validation numbers when a ticket is to be printed. Rather, the 

validation number is pre-loaded in the network interface board and is therefore 
immediately available. The pending credit indicia and the pre-loaded ticket validation 
number indicia may be a bar code, Arabic (or other human intelligible indicia), and the 
like. 

Another preferred embodiment of the invention provides a gaming machine 
adapted to print vahdated tickets for a game player. The gaming machine includes a 
15 microprocessor for controlling game operation (e.g., slot machine operation), a cashout 
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signal input, a network interface coupled to the microprocessor for communicating with a 
central authority, and a memory in the network interface that stores a pre-loaded ticket 
validation number received from the central authority. In addition, a ticket printer is 
coupled to the microprocessor for printing a ticket that includes pending credit indicia 
5 and pre-loaded ticket validation indicia in response to a cashout signal on the cashout 
signal input. After the ticket is printed, the gaming machine preferably sends record 
keeping information back to the central authority, hi particular, the record keeping 
information may include a pending credit identifier and ticket identifier. 

In another preferred embodiment, a gaming network includes a central authority, 
y 10 a central authority network interface coupled to the central authority and a network 
m medium, and one or more gaming machines. Each gaming machine generally includes a 

Si game controller for controlling game operation and a cashout signal input and a game 

P machine network interface coupled to the networic medium and to the game controller. In 

D addition, a ticket printer directly couples to the network interface for printing a ticket in 

:^ 1 5 response to the cashout signal and a ticket reader directly couples to the network interface 
for reading tickets. As a result, the central authority may exercise control over the ticket 
printer and ticket reader (and, optionally, a bill/coin validator) through the game machine 
network interface. 
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BRIEF DESCRIPTION OF THE DRAWINGS 


Figure 1 illustrates a block diagram of a gaming network. 

Figure 2 shows a front view of a ticket used with the gaming network. 

Figure 3 depicts a flow diagram for issuing a validated ticket from a gaming 
machine in the gaming network. 

Figure 4 shows a flow diagram for redeeming a ticket in a gaming network. 

Figure 5 illustrates a block diagram of a gaming network in which a central 
authority exercises direct control over a vaUdator, a ticket printer, and a ticket reader. 


DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 


nl 


Referring to Figure 1, a gaming network 100 includes several gaming machines 
102, 104, 106. The gaming machines 102-106 may be implemented, for example, as slot 

5 machines, video poker machines, video roulette machines, and the like. Each gaming 
machine 102-106 includes a game controller 108, a display 110, and a network interface 
112. The network interface 112 may be, for example, an RS485 interface such as that 
implemented by a Sentinel™ Interface from Casino Data Systems. Other interfaces and 
network architectures (e.g., Ethernet, parallel port, and the like) may be substituted 

10 however. Furthermore, the network interface 112 may adhere to, for example, the IGT 
Gaming SAS™ communication protocol, the CDS GDAP™ communication protocol, a 
custom protocol, or another third party communication protocol for establishing and 
maintaining communication with the gaming machine 102. The network interface 112 
may be physically present inside the gaming machine 102, or may be located externally 

15 and coupled to the gaming machine 102. Each gaming machine 102-106 further includes 
a coin acceptor 1 14, a bill vaHdator / ticket reader 116, and a ticket printer 118. 

As will be explained in more detail below, the game controller 108 is responsive 
to the cashout signal 134 to print a ticket 136 on paper, or other suitable material. 
Additionally, previously printed tickets (e.g., the ticket 138) may be redeemed by the 

20 gaming machines 102-106. The gaming network also includes a central authority or host 
computer system 120. The central authority 120 includes a ticketing database 122 and a 
network interface 124 for coxuiection over the network medium 126 to the gaming 
machines 102-106. Support systems connect to the central authority 120, including a 
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ticketing workstation 128, an administration workstation 130, and an accounting 
workstation 132. 

A dataport unit (DPU) 140 is provided as a data concentrator and buffering 
communication unit to address multiple gaming machines and to communicate with the 
poller 142. The poller 142, in tum, communicates with the DPU 140 and the central 
authority 120. The network interface 112 may be generally configured as shown in 
Figure 1 to include a CPU 144, a program and data memory 146, and a serial controller 
148. 

The game controller 108 is responsible for operation of the gaming device 102, 
Thus the game controller 108 may include a microprocessor, memory, game software, 
and support circuitry to implement a slot machine or other type of game. The display 110 
presents to the player a representation of the pending credit in the gaming machine 102 
(e.g., $455.50 as shown in Figure 1). During play, the game controller 108 tracks the 
pending credit according to the rules of the game and the interaction with the player 
(including the deposit of additional funds via the coin acceptor 114 and bill validator 
116), and further monitors for assertion of the cashout signal 134. Thus, the central 
authority 120 need not monitor the pending credit in each gaming machine 102-106, as 
each gaming machine 102-106 preferably tracks the pending credit locally and 
independently of the central authority 120. 

In response to the cashout signal 134, the game controller 108 prints the ticket 
136 which may be redeemed later at other gaming machines 102-106 or at independent 
workstations with ticket readers. The cashout signal 134 may be generated by a player 
actuated switch, touchscreen input, or the like. As will be explained m more detail 
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below, the game controller 108 prints the ticket 136 with a pre-loaded ticket validation 
number obtained from the central authority 120 through the network interfaces 112, 124 
and over the network medium 126. The central authority 120 uses an encryption 
algorithm to generate validation numbers. Preferably, the algorithm is based at least on 
5 time and/or date as well as a gaming machine number. 

The ticketing database 122, described in more detail with reference to Tables 1-3 
below, stores information obtained from the gaming machines 102-106, as well as locally 
generated validation numbers. The ticketing workstation 128 provides cash redemption 
of tickets outside of gaming machines, the administration workstation 130 provides an 
y 10 interface for setting up system parameters, and the accounting workstation 132 provides 
m for ticket and gaming machine accounting flmctions. Note that in general, when a ticket 

f validation number is pre-loaded onto the network interface board, the ticket validation 

number is also pre-stored in a ticketing database (albeit without an associated pending 

it; 

5 credit amount). Thus, should the gaming network fail, vahdation may still occur through 

IJ^ 1 5 human intervention. 

r Turning next to Figure 2, a ticket 200 includes a vahdation number bar code 202 

(e.g., in JCM or Code 205 format), a human intelhgible validation number 204, and a 
human intelhgible pending credit amount 206. The ticket 200, as shown, also includes a 
machine number 208 and a ticket number 210 (e.g., a sequential ticket number generated 
20 in the gaming machine 102). Note that the validation number bar code 202 is a machine 
readable representation of a pre-loaded vahdation number (as discussed in more detail 
below) but that the validation number bar code 202 generally does not encode other 
information (e.g., the pending credit amount). In other words, the ticket 200, when it is 
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advantageous to do so, may omit a machine readable pending credit amount. Additional 
infomiation may also be printed on the ticket 200, including a date/time of cashout, 
casino name, ticket expiration date, and the like. 

With regard to Figure 3, a flow diagram 300 shows a ticket printing method that 

5 may be implemented in hardware and/or software in the gaming device 102. In Figure 3, 
the Sentinel refers to the network interface 1 12, the poller refers to the poller 142, and the 
system / database refers to the central authority 120 and its ticketing database 122. The 
method includes monitoring (302) for a player to press a cashout button and thereby 
generate the cashout signal 134. Next, the method determines (304) whether a 

10 communication protocol (in this case SAS) is running on the gaming system 100 that 
supports central authority 120 generation of ticket vahdation numbers. If so, the method 
proceeds to obtain a pre-loaded validation number from the network interface 112 and 
print (306) the ticket. 

The method continues by sending (308) a ticket printing result (e.g., successful or 

15 unsuccessful) to the central authority 120 through the network interface 112. If the ticket 
is printed successfully, the method sends (310) ticket information for a Printed ticket to 
the central authority 120 through the network interface 112. The Printed ticket 
information includes Casino name, ticket date and time, vahdation number, a bar code 
representing the validation number, a numeric pending credit amount, an alphanumeric 

20 description of the pending amount, a machine number, and a ticket number (typically up 
to 9999 and sequentially generated at each gaming machine). Otherwise, the method 
sends (312) an In Progress lock for the ticket to the central authority 120. If the central 
authority 120 generates ticket validation numbers, then the network interface 112 
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requests (314) a new ticket validation number from the central authority 120. 
Subsequently, the network interface 112 receives (316) the new ticket vaUdation number 
and pre-loads it into a memory (e.g., the memory 146) for use before the next ticket is 
printed. Thus, a ticket validation number is immediately available when the player 
activates the cashout button. 

The ticketing database 122 in the central authority may store, for example, the 
fields set forth below in Table 1 for Ticket Information, Table 2 for Ticket Detail, and 
Table 3 for Ticket Information. 


Table 1 - Ticket Info 

Field 

Definition 

Description 

RecordNum 

Int 

Auto-incremented system transaction 
record number. 

ValidationDigits 

Tinyint 

# of digits in validation number 

VahdationNumber 

VarChar(32) 

Bar Code Number. 

MachineNumber 

Int 

Machine number printed on ticket 

TicketNumber 

Int 

Game's sequential ticket #, for 
example 0000 to 9999 

AmountType 

TinyInt 

See below. 

Amount 

Int 


Status 

TinyInt 

See below. 

StatusDateTime 

DateTime 

Application time of last Status change. 

IssuedDateTime 

DateTime 

Apphcation time table updated. 

IssuedAppID 

SmallInt 

Application code: 8=Poller. 

IssuedLocation ID 

Int 

Workstation,orPollerID If AppID=8 

IssuedID 

Int 

Machine number if AppID = Poller. 

PrintedDateTime 

DateTime 

Date & Time on ticket. 

PrintedAppID 

SmallInt 

Apphcation code: S^^PoUer 

PrintedLocation ID 

Int 

Workstation,or PoUerlD if AppID=-8 

PrintedID 

Int 

SlotMastJD if AppID = Poller. 
User ID if manually entered. 

PrintedOCR 

Char(lO) 

Player Card Number, if available. 

RedeemedDateTime 

DateTime 

Application time table updated. 

RedeemedAppID 

SmallInt 

Apphcation code: 8==Poller. 
19=Ticketing System. 
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RedeemedLocation ID 

Int 

Workstation,or PoUerlD if AppID=8 

RedeemedID 

Int 

SlotMastJD if AppID - Poller. 
User ID if manually redeemed. 

RedeemedOverridelD 

Int 

User ID of person who authorized 
override, if required for redeem. 

RedeemedOCR 

Char(lO) 

Player card number, if available. 

ExpiredDateTime 

DateTime 

Application time table updated. 

ExpiredAppID 

Smallint 

Application code: 8=Poller 

ExpiredLocation_ID 

Int 

PoUerlD if AppID-8, Workstation if 
AppID=19. 

ExpiredID 

Int 

User_ID for manual expiration. NULL 
if expired by Poller. 

VoidedDateTime 

DateTime 

Application time table updated. 

VoidedAppID 

Smallint 

Application code: 8=Poller. 

VoidedLocation ID 

Int 

Workstation^or PollerlD if AppID-=8 

VoidedID 

Int 

User ID for manual void. May be 
SlotMastJD or NULL if voided by 
Poller. 

DetailCount 

Int 

Number of detail records for ticket. 


Table 2 - Ticket Detail 

Field 

Definition 

Description 

RecordNum 

Int 


TimeStamp 

DateTime 

Application time table updated. 

GameDateTime 

DateTime 

Time on ticket if ActionCode=Printed. 

ValidationDigits 

Tinyint 

# of digits in ValidationNumber. 

ValidationNumber 

VarChar(32) 

Bar Code Number 

MachineNumber 

Int 

Machine number. 

AmountTi^e 

Tinyint 

See below. 

Amount 

Int 


ExpirationType 

Tinyint 

Present if ActionCode=Printed 

ExpirationDuration 

Smallint 

Present if ActionCode=Printed. 

ActionCode 

Tinyint 

Game/Sentinel event. See below. 

ResultCode 

Tinyint 

Event from System to Sentinel/Game 

ResultSubCode 

Int 

Error/warning code by System. 

Statusin 

Tinyint 

Status of ValidationNumber in Ticket 
Info before processing detail 
information. See below. 

StatusOut 

Tinyint 

Status of ValidationNumber in Ticket 
Info after processing detail 
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information. See below. 

OCR 

Char(lO) 

Player card number, if available. 

AppID 

Smallint 

Application code: S^Poller, Ticketing 
System=19 

Location ID 

Int 

Workstation,or PollerlD if AppID=8 

UpdatelD 

Int 

User ID, SlotMast ID if AppID=8 

OverridelD 

Int 

User ID if required for redemption. 

TransDate 

DateTime 

To match with buffer transactions. 

SitelD 

Tinyint 

Site of Poller or application 

PoUerlD 

Tinyint 

To match with buffer transactions. 

DpuID 

Tinyint 

To match with buffer transactions. 

SenID 

Tinyint 

To match with buffer transactions. 

SlotMast ro 

Int 

To match with buffer transactions. 

IsDamaged 

Char 

'N' or 'Y'. Defaults to 



Table 3 - Ticket Information 


Field 

Definition 

Description 


Vahdation Number 

VarcChar(32) 

Bar Code Number 


TimeStamp 

DateTime 

Application time row was added. 


LinkO 

Smallint 

Apphcation Code: 8= poller 

■- 

a y 

Link! 

Int 

Update ID 

If linkO^S then machine ID with 
redeem lock. Otherwise, UserlD with 
lock. 


Link2 

Int 

Location ID 
If link0=8 then Poller ID that locked. 
Otherwise, Workstation with lock. 


Turning next to Figure 4, a flow diagram 400 shows a ticket redemption method 
5 that may be implemented in hardware and/or software in the gaming network 100. In 
Figure 4, the Sentinel refers to the network interface 112, the poller refers to the poller 
142, and the system / database refers to the central authority 120 and its ticketing 
database 122. Beginning at step 402, a player inserts a ticket into a gaming machine. 
The gaming machine proceeds to query (404) the system for ticket validation of the 
10 validation number bar code 202. In general, the pending credit printed on the ticket is not 
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read by the ticket reader. Rather, the system itself responds with the pending credit as 
explained below. 

If the system responds (e.g., communication is up), then the system attempts to 
find the validation number in its database. If not found, the system responds (406) to the 
gaming machine with a Reject Message. Otherwise, the system checks the ticketing 
database 122 to determine if the ticket is a duplicate. If so, the system also responds 
(406) to the gaming machine with a Reject Message. If the validation number is not a 
duplicate, then the system determines whether the ticket status as recorded in the 
ticketing database 122 is issued and redeemable (i.e., it has not already been redeemed 
for money). If not, the system again responds (406) to the gaming machine with a Reject 
Message. The ticket / bill vahdator then rejects (408) the ticket. 

However, if the ticket was, in fact, successfully printed, the system responds (410) 
to the gaming machine (and the network interface 1 12) in particular, with the ticket type 
and the amount (e.g., in cents). If the gaming machine can accept the ticket (in the 
absence of a hardware problem, an amount not divisible by a certain unit, an amount too 
great for the game, and the like), then the game loads (412) the amount into its credit 
meter. Subsequently, the gaming machine replies (414) to the system with the ticket 
processing result (e.g., rejected or accepted). 

If the gaming machine accepted the ticket and credited its credit meter, then the 
system changes (416) the ticket status in the ticketing database 122 to Redeemed. As a 
result, the redeemed ticket is not useable to activate other gaming machines. Rather, 
additional tickets (or a ticket newly printed upon cashout) would be used to activate 
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additional gaming machines. Continuing with reference to Figure 4, if the ticket is not 
accepted, the ticket status remains (418) unchanged in the ticketing database 122. 

With reference next to Figure 5, a block diagram of a gaming network 500 
illustrates central authority control over a coin acceptor 514, a bill vaUdator / ticket reader 
516, and a ticket printer 518. Figure 5 is similar to Figure 1, and like reference numerals 
denote like parts. Note, however, that the coin acceptor 514, bill validator / ticket reader 
516, and ticket printer 518 are connected directly to the network interface 1 12 rather than 
to the game controller 108. 

As a resuh, the central authority 120 may exercise control over the coin acceptor 
514, bill vahdator / ticket reader 516, and ticket printer 518 through the network interface 
112. The game controller 108 is thereby reheved of those duties. Furthermore, existing 
gaming machines that do not allow convenient game controller ticket printing, reading, 
and bill validation may nevertheless issue and redeem tickets when fitted with the 
network interface 112. 

When a ticket is inserted into the ticket reader 516, the network interface 112 
reads the ticket directly and proceeds to verify the validation number bar code with the 
central authority 120 as explained above. Valid tickets resuU in credit applied to the 
gaming machine 102 using, for example, an Electronic Funds Transfer (EFT) message 
from the central authority 120. In addition, the network interface 112 may also read 
standard currency (e.g., bills and coins) and appropriately report to the central authority 
120. Again the central authority may respond with an EFT message to the gaming 
machine 102. Alternatively, the network interface 112 may determine the amount of 
standard currency inserted and report that amount directly to the gaming machine 102 
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(which may then appropriately increment its bill and coin meters). In that regard, the 
network interface 112 may act as a filter, such that only printed tickets generate 
appreciable network traffic to the central authority 120. 

Thus, the present invention provides a secure ticket actuated gaming network. In 
particular, the gaming machines pre-load ticket validation numbers in preparation for 
printing a cashout ticket. As a result, the player need not wait while the gaming machine 
generates or requests a new validation number. 

While the invention has been described with reference to a preferred embodiment, 
those skilled in the art will understand that various changes may be made and equivalents 
may be substituted without departing from the scope of the invention. In addition, many 
modifications may be made to adapt a particular step, structure, or material to the 
teachings of the invention without departing from its scope. Therefore, it is intended that 
the invention not be hmited to the particular embodiment disclosed, but that the invention 
will include all embodiments falling within the scope of the appended claims. 
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